home *** CD-ROM | disk | FTP | other *** search
/ The X-Philes (2nd Revision) / The X-Philes Number 1 (1995).iso / xphiles / hp48hor1 / iferr.txt < prev    next >
Text File  |  1995-03-31  |  8KB  |  176 lines
  1. (Comp.sys.handhelds) 
  2. Item: 2319 by billw at hpcvra.cv.hp.com. 
  3. Author: [William C Wickes] 
  4.   Subj: HP48 New IFERR II 
  5.   Date: Tue Mar 05 1991 17:52 
  6.  
  7.                       The Return of New IFERR 
  8.  
  9. The library listed at the end of this note is a new version of the 
  10. IFERR library previously posted, which corrects the problem associated 
  11. with command line execution.  You should delete version A of this library 
  12. if you still have it.  Please notify me if any problems arise with 
  13. version B. 
  14.  
  15. [Note!  The "A" version Bill refers to can be found on EduCALC Goodies Disk 
  16. #2.  Delete it!  The IFERR.LIB file on this disk obsoletes it.  -jkh-] 
  17.  
  18. Several HP 48 programmers have expressed a concern that the current error 
  19. trapping mechanism via IFERR is vulnerable to repeated ATTN key presses, which 
  20. can prevent a program from cleaning up when it is interrupted by the user. 
  21. This problem arises because IFERR and all other branching constructs built into 
  22. the HP 48 check to see if ATTN key has been pressed so that users cannot 
  23. (easily) lock themselves into an uninterruptible loop.   
  24.  
  25. The object listed below in ASC-> form is an HP 48 library titled "IF ERROR ver. 
  26. B", that provides an alternate version of IFERR/THEN which can be uniformly 
  27. substituted for the built-in versions.  The difference between this version and 
  28. that built into the HP 48 is in the handling of ATTN.  The ATTN key check is 
  29. disabled for the THEN clause of the version provided in this library, allowing 
  30. for an "unbreakable" recursive error recovery. 
  31.  
  32. Version B includes an additional modification.  The built-in IFERR...THEN 
  33. automatically clears the key buffer, and cancels pending execution of the 
  34. object associated with the key that started command line execution.  In version 
  35. B, the replacement IFERR does not clear keys.  A new command FLUSHKEYS is 
  36. provided, so that the programmer can control pending key execution.  FLUSHKEYS 
  37. takes no arguments, and clears the key buffer and the pending key object. 
  38.  
  39. An example of the use of the new IFERR is given in the program below.  In the 
  40. "main" program, a loop display a counter running from 1 to 1000.  If you press 
  41. ATTN while it is running, the error trap starts another counting loop, this 
  42. time from 1 to 50, to show you that an error termination sequence of some 
  43. length is running.  If you interrupt it, it just restarts itself. 
  44.  
  45. In the first line, a temporary variable, et, is allocated.  This variable will 
  46. hold the error termination procedure after it is created in the next part of 
  47. the program.  The error termination procedure is simply a cleanup procedure 
  48. protected by an IFERR which branches back to itself recursively if an error 
  49. occurs in its execution.  It is created in a list to avoid the inclusion of the 
  50. opening and closing program quotes, which themselves have attention key checks. 
  51. The remainder of the program is protected by IFERR...THEN et EVAL END.   
  52.  
  53. Notes: 
  54. * You must access the error termination procedure via a temporary variable 
  55. because global variable execution itself contains an attention key check. 
  56.  
  57. * If your cleanup procedure has an unavoidable error, the only way to stop 
  58. infinite execution is by [ON]-[C]. 
  59.  
  60. * The library (which has ID 1793) is auto-attaching: to use it, all you need to 
  61. do is store it in a port (port 0, say) by putting it on the stack and executing 
  62. :0:1793 STO, and then turning the HP 48 off and on. 
  63.  
  64. * To convert old programs containing IFERR to the new version, you need only to 
  65. EDIT (VISIT), then ENTER when the library is attached.  Downloading a program 
  66. in ASCII form via kermit will also automatically use the new IFERR. 
  67.  
  68. Bill Wickes 
  69. HP Corvallis 
  70.  
  71. Sample error trap program mentioned above [called TRAP on this disk. -jkh-]: 
  72. ----------------- cut here ---------------------------------------------- 
  73. %%HP: T(3)A(R)F(.); 
  74. \<< 0 \-> et 
  75.   \<< { IFERR 1 50 
  76.              FOR j 
  77.               "YOUR CLEANUP PROC." 1 DISP 
  78.               "#" j \->STR + " HERE" + 2 DISP 
  79.              NEXT 
  80.         THEN et EVAL 
  81.         ELSE DONE 
  82.         END } OBJ\-> DROP 
  83.     'et' STO 
  84.     IFERR 1 1000 
  85.       FOR j 
  86.         "YOUR MAIN PROC." 1 DISP 
  87.         "#" j \->STR " NOW" + + 2 DISP 
  88.       NEXT 
  89.     THEN et EVAL 
  90.     END 
  91.   \>> 
  92. \>> 
  93. ----------------- cut here ---------------------------------------------- 
  94.  
  95. (Comp.sys.handhelds) 
  96. Item: 2405 by _macrokid at hpcvbbs.UUCP 
  97. Author: [Kevin Vashi] 
  98.   Subj: IFERR Problem. 
  99.   Date: Tue Mar 12 1991 
  100. ---------- 
  101.   Resp: 1 of 1 by billw at hpcvra.cv.hp.com. 
  102. Author: [William C Wickes] 
  103.   Date: Wed Mar 13 1991 17:52 
  104.  
  105. Kevin Vashi writes: 
  106.  
  107. > If you have created programs that have the IFERR..THEN..END structure 
  108. > after the IFERR library is attached then, after unattaching or purging 
  109. > the IFERR library leads to the replacement of IFERR structure by 
  110. > XLIB 1793 0 object. 
  111.  
  112. This is not a defect, it's the correct behavior.  When you remove a library, 
  113. the 48 can no longer display by name, or execute, any commands from that 
  114. library.  The best it can do is display the library number and the command 
  115. number as XLIB n m. 
  116.  
  117. The confusion here might arise from the use of "IFERR" for the name of the 
  118. new structure word, which might suggest that the library somehow modifies 
  119. the behavior of the built-in IFERR.  Actually, when you enter a program 
  120. containing IFERR, if the library is present it compiles as a (XLIB) reference 
  121. to the new version.  External libraries are searched before the internal ones, 
  122. so a library can always supersede a built-in command or structure word with 
  123. a new one of the same name. 
  124.  
  125. Bill Wickes 
  126. HP Corvallis 
  127.  
  128. ------------------------------------------------------- 
  129.  
  130. (Comp.sys.handhelds) 
  131. Item: 2397 by k36853p at saha.hut.fi 
  132. Author: [Tapani Otala] 
  133.   Subj: New IFERR and libraries in general 
  134.   Date: Tue Mar 12 1991 
  135. ---------- 
  136.   Resp: 1 of 1 by billw at hpcvra.cv.hp.com. 
  137. Author: [William C Wickes] 
  138.   Date: Tue Mar 12 1991 
  139.  
  140. >       a) Seems that using the new IFERR posted by Dr. Wickes 
  141. >          last week screws up the indentation of RPL programs. 
  142. >          Any way to correct this? 
  143.  
  144. The program decompiler built into the 48 doesn't recognize the library IFERR, 
  145. which messes up the orderly indentation.  There's no fix for this. 
  146.  
  147. >       b) Seems that DETACH does not complain when attempting to 
  148. >          detach a library _not_ attached to the current directory. 
  149. >          Now, is there a _simple_ way to find out into _which_ 
  150. >          directory a library is attached? 
  151.  
  152. The information about which library is attached to a subdirectory is stored 
  153. in the directory, not the library.  Hence there is no simple way to 
  154. catalog library attachments. 
  155.  
  156. >          I know I could use LIBS to determine whether the library 
  157. >          is _not_ attached to the current directory, but its 
  158. >          not good enough.  I suppose LIBS used with a directory 
  159. >          traversal routine could be used to locate the correct 
  160. >          directory, but its a real drag. Plus I am not entirely 
  161. >          sure about the uniqueness of the result. 
  162.  
  163. This is the only way to do it; but note that a particular library can be 
  164. attached to any number of directories. 
  165.  
  166. >       c) When I PURGE a detached library, the display jerks sideways 
  167. >          about one half of the screen. Is this supposed to happen? 
  168.  
  169. This is normal and harmless.  The library configuration table is stored 
  170. at a lower address than the display RAM, so when the table shrinks, the 
  171. display jerks while memory is being merged.  I actually "use" this effect 
  172. to give me confirmation that the purge has actually happened. 
  173.  
  174. Bill Wickes 
  175. HP Corvallis 
  176.